When running a large Software-as-a-Service (SaaS) provider, there are often many services created by disparate teams running over different network protocols that need to appear as a coherent set of products/services to customers, partners, and the larger developer community that will use that set of subservices as a platform. A primary challenge for some SaaS providers is obtaining a centralized identity service, so that there is one user name and authentication mechanism (e.g., password) that works across all of the subservices. Once a user is identified, the next hurdle is to determine which, if any, services the user is authorized to access.
Several authorization systems that have been built in the past assume that if a user can access the service, there are a very fixed set of static permissions for which pieces of the service the user is entitled to use. This approach does not always work well, particularly for enterprises which prefer very fine-grained control over which users can use each feature of a service. Often, these enterprises like to use groups or roles to assign similar permissions to sets of users.
For security reasons, authorization decisions are performed server-side, since client applications are under control of untrusted parties, perhaps having been written entirely by untrusted parties in a fully-realized developer community scenario. However, clients often want to know what operations they are allowed to perform, so that they can disable or remove the portions of the user experience that the user is not allowed to access, rather than waiting for the user to try something that is going to fail.
In many enterprises, there are hundreds of millions of users and thousands of servers. With aggressive virtualization, services may be distributed across hundreds of thousands of servers. Therefore, complex, tightly-coupled, or centralized processing is best kept to a minimum. In particular, on the server side, the latency requirement dictates that processing can be simplified and calls to other internal services can be kept to a minimum.